Durant la première partie de la session, le speaker a développé un Workflow avec la couche Workflow Foundation pour SharePoint. En effet, SharePoint étant construit sur .NET 3.0, la couche WF est donc présente, et SharePoint devient alors l'application hôte qui hébergera, stockera et exécutera vos Workflows. Bref, rien de nouveau sous les tropiques.

Dans la deuxième partie de la démonstration, nous avons vu comment faire appel à un service WCF depuis un Workflow exécuté dans SharePoint. Lorsque dans un projet quelconque .NET vous ajoutez une référence à un service WCF, Visual Studio ajoute un fichier de configuration app.config. Dans ce fichier se trouve un élément important, le EndPoint ou point d'accès. En effet, cette information va permettre à votre application cliente d'attaquer ce service.

   1:  <endpoint address=""

   2:        binding="wsHttpContextBinding"

   3:        contract="WFServiceLibrary2.IWorkflow1">

   4:  </endpoint>

Comme vous vous en doutez, SharePoint n'a aucune connaissance de ce fichier de configuration, il faudra donc ajouter ce point d'accès dans le web.config de la / les application(s) web qui auront besoin d'accéder à ce service. Je rappelle que dans un souci de déploiement propre, il n'est pas conseillé d'éditer directement le fichier web.config. Optez pour la manipulation du fichier de configuration via une feature, et pour ça appuyez vous sur la librairie SharePointOfView.

Et pour boucler la boucle, lorsque vous instancierez votre service depuis votre application SharePoint, vous enverrez au constructeur le nom du point d'accès, endpoint, référencé dans le fichier web.config. Cette approche apporte quand outmême beaucoup d'ouverture, et une fois de plus SharePoint se montre comme une plateforme applicative puissante (bon ok, c'est grâce à .NET tout ça).